View COREDDR-M_871864.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

coreddr v4.0 handbook
actel corporation, mountain view, ca 94043 ? 2008 actel corporation. all rights reserved. printed in the united states of america part number: 50200109-2 release: july 2009 no part of this document may be copied or reproduced in any form or by any means without prior written consent of actel. actel makes no warranties with respect to this do cumentation and disclaims any implied warranties of merchantability or fitness for a particular purpose. information in this document is subject to change without notice. actel assumes no responsibility for any errors that may appear in this document. this document contains confidential proprietary information that is not to be disclosed to any unauthorized person without prior written consent of actel corporation. trademarks actel, igloo, actel fusion, proasic, libero, pigeon point and the associated logos are trademarks or registered trademarks of actel corporation. all other trademarks and service marks are the property of their respective owners.
3 table of contents introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 key features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 supported device families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 core versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 coreddr device utilization and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 functional block description . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 address mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 coreddr operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 standard ddr configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 instruction timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 tool flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 smartdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 importing into libero ide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 simulation flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 synthesis in libero ide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3 coreddr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 controller configuration ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 core interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 local bus signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 ddr sdram interface signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5 timing diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 sdram writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 sdram reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 auto-precharge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6 testbench operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 testbench description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 verilog user testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 vhdl user testbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7 implementation hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 data capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8 ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 ordering codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
table of contents coreddr v4.0 4 a list of document changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 b product support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 customer service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 actel customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 actel technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 contacting the customer technical support center . . . . . . . . . . . . . . . . . . . . . . . . 37 index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 introduction general description coreddr provides a high-performance interface to doub le data rate (ddr) synchronous dynamic random access memory (sdram) devices. coreddr accepts read and write commands using the simple local bus interface and translates these requests to the command sequences re quired by sdram devices. coreddr also performs all initialization and refresh functions. coreddr uses bank management techniques to monitor the status of each sdram bank. banks are only opened or closed when necessary, minimizing access delays. up to four banks can be managed at one time. access cascading is also supported, allowing read or write requests to be chained toge ther. this results in no delay between requests, enabling up to 100% memory throughput for sequential accesses. key features coreddr is a highly configurable core and has the following features: ? high performance, double data rate cont roller for standard sdram chips and dimms ? synchronous interface, fully pipelined internal architecture ? supports up to 1,024 mb of memory ? bank management logic monitors st atus of up to four sdram banks supported device families ? proasic3?e ?fusion core versions this handbook applies to coreddr v4.0. coreddr device utilization and performance table 1 gives device utilization and performance for actel coreddr. table 1 coreddr device utilization and performance family cells or tiles utilization performance sequential combinatorial total device total proasic3e 795 953 1,748 a3pe600-2 12% 133 mhz fusion 795 953 1,748 afs600-2 12% 133 mhz note: all data was obtained using a typical system configuration with the local bus tied to internal user logic and the controller configuration inputs hardcoded during synthesis.

7 1 functional block description figure 1-1 typical coreddr system 1 coreddr is provided with runtime-programmable inpu ts for all timing parameters (cas latency, t ras , t rc , t rfc , t rcd , t rp , t mrd , t rrd , t refc , t wr ) and memory configuration settings. this ensures compatibility with virtually any sdram configuration. coreddr is also available in netlist format with user-defined timing and memory configuration parameters for designs requ iring low logic utilization or for desi gns requiring high-clock-rate operation. coreddr consists of the following primary blocks, as shown in figure 1-2 on page 8 : 1. control and timing block C main controller logic 2. initialization control C performs in itialization sequence after reset_n is deactivated or sd_init is pulsed. 3. address generation C puts out address, bank addr ess, and chip select signals on sdram interface. 4. bank management C keeps track of last opened row and bank to minimize command overhead. 5. refresh control C performs automatic refr esh commands to maintain data integrity. 6. ddr data control C handles multiplexing and demultip lexing of data to and from the ddr sdram devices. for the ddr sdram controller, the data passes through the controller, and the controller handles all ddr-related synchronization and timing generation . the ddr sdram controller uses a C90 phase-shifted system clock to capture read data in the center of the data window. the core also has separate datain and dataout busses at the user interface. these busses are twice as wide as the data bus going to the ddr sdram. this multiplexing is required because the local (user) interface operates at single data ra te, whereas the sdram data interface operates at double data rate. user system ddr sdram device(s) coreddr pll/dll 1 ?90 1 actel fpga core system clock user interface local bus ddr sdram interface clk_1x clk_1x_sh90 clk_1x 1. the external tristate buffers shown in figure 1-1 reside in the i/o. the output enables of the tristate buffers are controlled by coreddr.
functional block description coreddr v4.0 8 figure 1-2 ddr sdram controller block diagram bank management refresh control control and timing cke ras_n cas_n we_n initialization control address generation sa[13:0] ba[1:0] cs_n[7:0] reset_n configuration inputs raddr b_size[3:0] r_req w_req rw_ack d_req r_valid d_valid coreddr clock dq sdram device(s) ddr data control datain[2n?1:0] dataout[2n?1:0] dm_in[2n/8?1:0] pll/dll dm[n/8?1:0] dqs dq_oe[n/8?1:0] dq_out[n/8?1:0] dq_in[n/8?1:0] dqs_oe[n/8?1:0] dqs_out[n/8?1:0] clk_1x clk_1x_sh90 1 1 ?90 local bus interface ddr sdram interface
coreddr v4.0 address mapping 9 address mapping the mapping of the raddr bus at the local bus interface to the chip select, row, column, and bank addresses is shown in figure 1-3 . the exact bit positions of the mapping will vary de pending on the rowbits and colbits configuration port settings. the column bits, bank bits, row bits, and chip select are mapped from the least significant bits of raddr. by mapping the bank bits from this location, long accesses to cont iguous address space are more likely to take place without the need for a precharge. figure 1-3 mapping of raddr to sdra m chip select, row, column, and bank coreddr operation the synchronous interface and fully pipelined internal archit ecture of sdram allow extremely fast data rates if used efficiently. sdram is organized in banks of memory addr essed by row and column. the number of row and column address bits depends on the size and configuration of the memory. sdram is controlled by bus commands formed using combinations of the ra s_n, cas_n, and we_n signals. for instance, on a clock cycle where all three signals are high, the associated command is a no operation (nop). a nop is also indicated when the chip select is not assert ed. the standard sdram bus commands are shown in table 1-1 . sdram devices are typically divided into four banks. these banks must be opened before a range of addresses can be written to or read from. the row and bank to be opened are registered coincident with the active command. when a new row on a bank is accessed for a read or a write, it may be necessary to first close the bank and then reopen the bank to the new row. a bank is closed using the precharge command. opening and closing banks costs memory bandwidth, so coreddr has been designed to monitor and manage the stat us of the four banks simultaneously. this enables the controller to intelligently open and close banks only when necessary. when a read or write command is issued, the initial column address is presented to the sdram devices. in the case of ddr sdram, the initial data is presented one clock cycle after the write command. for the read command, the initial raddr column[colbits?1:0] bank[1:0] row[rowbits?1:0] cs_n[7:0] (demuxed) msb lsb 3 rowbits colbits 2 table 1-1 sdram bus commands command ras_n cas_n we_n nop h h h active l h h read h l h write h l l burst terminate h h l precharge l h l auto-refresh l l h load mode register l l l
functional block description coreddr v4.0 10 data appears on the data bus 1C4 clock cycles later. this delay, known as cas latency, is due to the time required to physically read the internal dram and register the data on the bus. the cas latency depends on the speed grade of the sdram and the frequency of the memory clock. in general, the faster the clock, the more cycles of cas latency required. after the initial read or write command, sequential reads and writes will continue until the burst length is reached or a burst terminate command is issued. sdram devices support a burst length of up to eight data cycles. the sdram controller is capable of cascading bursts to maximize sdram bandwidth. sdram devices require periodic refresh operations to maintain the integrity of the stored data. coreddr automatically issues the auto-refresh command periodically. no user intervention is required. the load mode register command is used to configure sdram operation. this register stores the cas latency, burst length, burst type, and write burst mode. the sdram controller supports sequential burst type and programmed- length write burst mode. an additional extended mode regist er is used to control the integrated delay-locked loop (dll) and the dq output drive strength. the ddr controller writes to the base mode register and extended mode register during the initialization sequence. consult the sd ram device specification for additional details on these registers. standard ddr configurations to reduce pin count, sdram row and column addresses are multiplexed on the same pins. table 1-2 lists the number of rows, columns, banks, and chip selects requ ired for various standard discrete ddr sdram devices. coreddr will support any of these devices. sdram is typically available as dual in-line memory modules (dimms), small outline dimms (so-dimms), and discrete chips. the number of row and column bits for a dimm or so-dimm configuration can be found by determining the configuration of the disc rete chips used on the module. this in formation is available in the module datasheet. table 1-2 standard ddr sd ram device configurations chip size configuration rows columns banks 64 mb 16m4 12 10 4 64 mb 8m8 12 9 4 64 mb 4m16 12 8 4 64 mb 2m32 11 8 4 128 mb 32m4 12 11 4 128 mb 16m8 12 10 4 128 mb 8m16 12 9 4 128 mb 4m32 12 8 4 256 mb 64m4 13 11 4 256 mb 32m8 13 10 4 256 mb 16m16 13 9 4 512 mb 128m4 13 12 4 512 mb 64m8 13 11 4 512 mb 32m16 13 10 4 1,024 mb 256m4 14 12 4 1,024 mb 128m8 14 11 4 1,024 mb 64m16 14 10 4
coreddr v4.0 instruction timing 11 instruction timing initialization after reset_n is deasserted or sd_init is pu lsed, coreddr performs the following sequence: 1. nop command for 200 s (delay controlled by the delay port parameter) 2. precharge-all command 3. extended load mode register command to enable the ddr sdram dll 4. load mode register command with dll reset bit set 5. precharge-all command 6. two auto-refresh commands 7. load mode register command with dll reset bit clear and proper mode settings 8. read/write requests held off for 200 cloc k cycles to allow for dll to stabilize coreddr initialization timing is shown in figure 1-4 . figure 1-4 ddr initialization sequence clk reset_n cke sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n 0500 mode 10 ff 00 00 00 00 00 00 00 200 s of nop initialization complete 200 clks t rp t mrd t mrd t rp t rfc t rfc
functional block description coreddr v4.0 12 auto-refresh sdram devices require periodic auto-refresh commands to maintain data integrit y. coreddr will automatically issue periodic auto-refresh commands to the sdram device(s) without user intervention. the refresh period configuration port (ref) specifies the period between refreshes, in clock cycles. figure 1-5 shows an example of two refresh commands. the first refresh sequence o ccurs when one or more banks have been left open as a result of a read without precharge or write without precharge operation. all open banks are closed using the precharge-all command (ras_n, we_n asserted with sa[10] an d sa[8]) prior to the refresh command. in figure 1-5 , a refresh occurs again after the refresh period has elapsed, as determ ined using the ref configuration port. the refresh will never interrupt a read or write in the middle of a data burst. ho wever, if the controller determines that the refresh period has elapsed at a point concurrent with or prior to a read or write request, the request may be held off (rw_ack will not get asserted) until after the refresh has been performed. figure 1-5 refresh timing bank management c oreddr incorporates bank management techniques to minimize command overhead. for each bank, the controller records the last opened row and whether the bank has been closed. when a local bus interface read or write request occurs, coreddr determines if the requested bank has already been opened and whether the request is for the same row as the one the bank is already opened to. if the bank is already opened to the requested row, coreddr performs the function immediately. if the bank was previously opened with a different row and was not closed, the controller closes the previously opened bank (using the precharge command) and reopens the bank (using the active command) to the requested row. if the bank is already closed, the controller opens the bank to the requested row (using the active command). requests to the controller can be issued as read with auto-precharge , write with auto-precharge , read without auto-precharge , and write without auto-precharge . commands are issued with auto-precharge if the auto_pch signal is set concurrent with the read request (r_req) or wr ite request (w_req) signal. after a read with auto-precharge or write with auto- precharge , the accessed bank is automatically closed internally by the sdram devices. after a read without auto- precharge or write without auto-precharge , the accessed bank is left open until cl osing is required. closing occurs whenever a request is issued to a row other than the one the bank is already open to, or during the next refresh sequence. the refresh sequence will close all the banks (using the precharge-all command) if all banks are not already closed. the default configuration of the controller tracks the status of four banks at a time. this means that accesses to row a on bank a on chip select a is considered to be on a different row from row a on bank a on chip select b . therefore, a close-and- open sequence is performed when switching between these rows. t rp t refc clk sa[13:0] ba[1:0] cs_n[7:0] ras_n cas_n we_n 0500 0 00 00 00
13 2 tool flows licenses coreddr is licensed in two ways. depending on your license, tool flow functionality may be limited. obfuscated complete rtl code is provided for the core, enabling th e core to be instantiated with smartdesign. simulation, synthesis, and layout can be performed with actel libero? integrated design environment (ide). the rtl code for the core is obfuscated, and some of the testbench source files are not provided. they are pre-compiled into the compiled simulation library instead. rtl complete rtl source code is provided for the core and testbenches. smartdesign the core can be configured using the configur ation gui within smartdesign, as shown in figure 2-1 . figure 2-1 coreddr configuration within smartdesign
tool flows coreddr v4.0 14 importing into libero ide libero ide is available for download to the smartdesign ip catalog, via the libero ide web repository. for information on using smartdesign to instan tiate, configure, connect, and generate cores, refer to the libero ide online help. simulation flows to run simulations, select the user testbench within the smartdesign coreddr configuration gui, right-click, and select generate design. when smartdesign generates the design files, it will install the appropriate testbench files. to run the simulation, set the design root to the coreddr instantiation in the libero ide design hierarchy pane, and click the simulation icon in the libero ide design flow window. this will invoke model sim ? and automatically run the simulation. synthesis in libero ide set the design root appropriately and click the synthesis icon in the libero ide. the synthesis window appears, displaying the synplicity? project. set synplicity to use the verilog 2001 standard if verilog is being used. to perform synthesis, click the run icon. place-and-route in libero ide having set the design root appropr iately and run synthesis, click the layout icon in actel libero ide to invoke designer. coreddr requires no special place-and-route settings.
15 3 coreddr generics customers can define the generics listed in table 3-1 as required in the source code. table 3-1 coreddr generics generic default setting description fpga family 16 must be set to match the supported fpga family. 16: proasic3e 17: fusion pll input frequency 133 mhz the input frequency can be set to the following values: 33 mhz, 66 mhz, and 133 mhz. program second pll with this delay 1.335 ns this delay is needed to capture the data properly. the data capture is explained in detail in implementation hints on page 29 . the following delay values are supported: 0: disable 1: 0.735 ns 2: 0.935 ns 3: 1.135 ns 4: 1.335 ns 5: 1.535 ns 6: 1.735 ns 7: 1.935 ns 8: 2.135 ns 9: 2.335 ns 10: 2.535 ns 11: 2.735 ns 12: 2.935 ns 13: 3.135 ns 14: 3.335 ns 15: 3.535 ns sdram_dsize 64 local side data width sdram_chips 8 number of chip selects sdram_colbits 12 maximum number of sdram column bits sdram_rowbits 14 maximum number of sdram row bits sdram_chipbits 3 number of encoded chip select bits sdram_bankstatmodules 4 number of bank status modules used (in multiples of four) sdram_nibble_dqs 0 for the ddr sdram controller, the typical configuration implements one dm and dqs per byte of dq bits. some memories are arranged with one dm and one dqs per nibble of dq bits. coreddr can be configured to support one dm and one dqs per nibble of dq bits.
coreddr coreddr v4.0 16 controller configuration ports coreddr is configured using runtime-programmable configurat ion ports. these ports may be tied off by the user to fixed values or programmed at runtime. these values should not change after reset_n is deasserted. table 3-2 lists the configuration ports. table 3-2 coreddr controller parameters parameter port bits valid values description ras 4 1C10 sdram active to precharge (t ras ), specified in clock cycles rcd 3 2C5 sdram active to read or write delay (t rcd ), specified in clock cycles rrd 2 2C3 sdram active bank a to active bank b (t rrd ), specified in clock cycles rp 3 1C4 sdram precharge command period (t rp ), specified in clock cycles rc 4 3C12 sdram active to active/auto-refresh command period (t rc ), specified in clock cycles rfc 4 2C14 auto-refresh to active/auto-refresh command period (t rfc ) specified in clock cycles mrd 31C7 sdram load mode register command to active or refresh command (t mrd ), specified in clock cycles cl 3 1C4 sdram cas latency, specified in clock cycles cl_half 1 0C1 ddr sdram half clock latency. specifies half clock of latency in addition to cl. bl 20C3 sdram maximum burst length (encoded). this value refers to the number of local side transfers per burst (one local side transfer resu lts in two transfers to the ddr device). values are decoded as follows: 0 C 1 transfer/burst 1 C 2 transfers/burst 2 C 4 transfers/burst 3 C 8 transfers/burst (valid for sdr sdram devices only) ds 2 0, 1, 3 ddr drive strength setting programmed into extended mode register (emr) bits 6 and 1. values mapped to emr as follows (refer to dd r sdram device datashee t for description of drive strength settings): 0 C emr[6] = 0, emr[1] = 0 1 C emr[6] = 0, emr[1] = 1 3 C emr[6] = 1, emr[1] = 1 wr 2 1C3 sdram write recovery time (t wr ) delay 16 10C65,535 controllers delay after a reset event before initializing the sdram, specified in clock cycles. per jedec standards, ddr devices require this delay to be a minimum of 200 s. ref 16 10C65,535 period between auto-refresh commands issued by the controller, specified in clock cycles ref = auto-refresh interval/t ck colbits 3 3C7 number of bits in the column address (e ncoded). values are decoded as follows: 3 C 8 column bits 4 C 9 column bits 5 C 10 column bits 6 C 11 column bits 7 C 12 column bits
coreddr v4.0 controller configuration ports 17 for example: if rcd is 20 ns in the specification and the clock is 13 3 mhz, then the number of clocks is equal to 20 7.5 = 3. you must hardcode the rcd ports to the binary value 011 in the top level, since the value is "3". example settings for the timing-related parameters are shown in table 3-3 . these settings are based on the speed grade of the sdram devices and the desired operating frequency. consult the datasheet fo r the sdram device you are using for the specific timing values of that device. rowbits 2 0C3 number of bits in the row address (enc oded). values are decoded as follows: 0 C 11 row bits 1 C 12 row bits 2 C 13 row bits 3 C 14 row bits regdimm 1 0C1 set when using registered/buffered dimm. causes adjustment in local bus interface timing to synchronize with sdram command timing, delayed by register/buffer on dimm. table 3-2 coreddr controll er parameters (continued) parameter port bits valid values description table 3-3 example controller parameter values for coreddr parameter 133 mhz (7.5 ns period) 1 167 mhz (6 ns period) 2 200 mhz (5 ns period) 3 specification value specification value specification value ras 40.0 ns 6 42.0 ns 7 40.0 ns 8 rcd 20.0 ns 3 18.0 ns 3 15.0 ns 3 rrd 15.0 ns 2 12.0 ns 2 10.0 ns 2 rp 20.0 ns 3 18.0 ns 3 15.0 ns 3 rc 65.0 ns 9 60.0 ns 10 55.0 ns 11 rfc 75.0 ns 10 72.0 ns 12 70.0 ns 14 mrd 15.0 ns 2 12.0 ns 2 10.0 ns 2 cl C 2 C2C3 cl_halfC 1 C1C0 wr 15.0 ns 2 15.0 ns 3 15.0 ns 2 delay 200 s 26,667 200 s 33,334 200 s 40,000 ref 7.8125 s 1,041 7.8125 s 1,302 7.8125 s 1,562 notes: 1. values based on micron mt46v64m8-75 2. values based on micron mt46v64m8-6t 3. values based on micron mt46v64m8-5b

19 4 core interfaces the port signals for coreddr are defined in table 4-1 , table 4-2 on page 20 , and table 3-2 on page 16 , and illustrated in figure 1-3 on page 9 . all signals are designated either input (input only) or output (output only). local bus signals the user interface to coreddr is referred to as the local bus interface. the local bus signals are shown in table 4-1 . table 4-1 local bus signals signal name i/o description clk_in clock input system input clock. all local in terface signals are synchronous to this clock. clk_1x clock output 1 system clock. clk_1x_sh90 clock output a 90 o phase-shifted version of system clock reset_n reset input system reset raddr[30:0] memory address input local interface address b_size[3:0] burst size input local interface burst length. valid values are 1 through bl, where bl is the programmed burst length. (refer to table 3-2 on page 16 for a discussion of the bl parameter.) r_req read request input local interface read request w_req write request input local interface write request auto_pch auto-precharge request input when asserted in conjunction with r_req or w_req, causes command to be issued as read with auto-precharge or write with auto-precharge , respectively. rw_ack read/write acknowledge output acknowledgment of read or write request d_req data request output requests data on the local interface write data bus (datain) during a write transaction. asserts one clock cycle prior to when data is required. w_valid write data valid output frames the active data being written to sdram. mimics d_req, except it is delayed by one clock cycle. this signal is typically not used and is retained for legacy compatibility. r_valid read data valid output indicates that the data on the local interface read data bus (dataout) is valid during a read cycle. sd_init initialization strobe input causes the sdram controller to rei ssue the initialization sequence to sdram devices. the sdram controller will always issue the initialization sequence (including the startup delay) after reset, regardless of the sd_init state. this signal can be tied low if runtime reinitialization is not required. datain[2nC1:0] input data input input data bus. this data bus is twice the width of the ddr sdram data bus. dataout[2nC1:0] output data output output data bus. this data bus is twice the width of the ddr sdram data bus. dm_in[2n/16-1:0] data mask input masks individual bytes during data write. notes: 1. the n value in vector indexing refers to data width to sdram interface. 2. all control signals are active high except reset_n. 3. all local interface signals are synchronous to clk_1x.
core interfaces coreddr v4.0 20 ddr sdram interface signals the external interface to sdram devices is referred to as the sdram interface. the sdram interface signals are shown in table 4-2 . table 4-2 ddr sdram interface signals signal name i/o description sa[13:0] address bus output sampled during the active , precharge , read , and write commands. this bus also provides the mode register value during the load mode register command. ba[1:0] bank address output sampled during active , precharge , read , and write commands to determine which bank command is to be applied to. cs_n[7:0] chip selects output sdram chip selects cke clock enable output sdram clock enable. held low during reset to ensure sdram dq and dqs outputs are in the high-impedance state. ras_n row address strobe output command input cas_n column address strobe output command input we_n write enable output command input dq_out[nC1:0] data bus output output sdram data bus output to external tris tate buffers. this data bus is half the width of the datain and dataout busses. dqin[nC1:0] data bus input input sdram data bus input. this data bus is half the width of the datain and dataout busses. dq_oe[n/8C1:0] data bus output enable output sdram data bus output enable. used to control external tristate buffers to ddr sdram. dm[n/8C1:0] data mask output masks individual bytes during data write. multiplexed version of the dm_in input to the controller. dqs_out[n/8C1:0] data strobe output output strobes data into the sdram devices during writes. dqs_oe[n/8C1:0] data strobe output enable output used to control external tristate buffers for data strobe. notes: 1. the n value in vector indexing refers to data width to sdram interface. 2. all control signals are active high except reset_n. 3. all local interface signals are synchronous to clk_1x.
21 5 timing diagrams sdram writes the user requests writes to the local bus interface by asse rting the w_req signal and driv ing the starting address and burst size on raddr and b_size, respectively. the auto_p ch signal can also be asserted with w_req to cause the write to be issued as a write with auto-precharge . the rules for write requests to the local bus interface are as follows: 1. once w_req is asserted, it must remain asserted until rw_ack is asserted by coreddr. after rw_ack is asserted by coreddr, w_req may remain asserted to re quest a follow-on write transaction. w_req may remain asserted over any number of rw_ack pulses to genera te any number of cascaded write bursts. the only time w_req may be deasserted is during the clock cycle immediately following the rw_ack pulse from coreddr. 2. raddr, b_size, and auto_pch must maintain static values from the point when w_req becomes asserted until coreddr asserts rw_ack. raddr, b_size, and auto_pch may only change values in the clock cycle immediately following the rw_ack pulse from coreddr, or when w_req is deasserted. 3. the w_req signal may not be asserted while the read request (r_req) signal is asserted. 4. the data request (d_req) signal will assert one clock cycle prior to when the user must present data on the datain bus. 5. the timing relationship between an initial w_req an d rw_ack assertion, or between rw_ack pulses as a result of multiple cascaded writes, will vary depending on the status of the banks being accessed, configuration port settings, refresh status, and initialization status. the user logic should not rely on an y fixed timing relationship between w_req and rw_ack. example coreddr write sequence figure 5-1 on page 22 shows an example ddr sdram controller write sequence. in this sequence, three writes are requested, all to the same row. the first and second write requ ests are for a burst size of four, and the third is for a burst size of two. the write request (w_req) signal is first as serted along with the starting address (raddr) and the burst size (b_size). as a result of this request, the ddr sd ram controller asserts the row address (sa), bank address (ba), and chip select (cs_n) with the active command to open the bank to the requested row. next, the ddr sdram controller requests data from the user through the local interface using the d_req signal, and acknowledges the write request by asserting rw_ack. the ddr sdram controller begins writing the data to the sdram devices by issuing the write command and presenting the ddr data and the dqs clock. for this request, four data transfers occur to the local interface, which translates to eight data transfers to the sdram interface. the local interface write request (w_req) remains asserted after rw_ack asserted by the ddr sdram controller to request an additional write burst. after the rw_ack puls e, the local interface changes the address (raddr) but keeps the burst size (b_size) at four. the ddr sdram controller issues the next write command, and data transfers to the sdram interface immediately following the first burst. after the second write request, the ddr sdram controller continues to assert w_req to cause a third burst. for this write, the burst size (b_size) is reduced to two. sinc e the burst size of the second write request is less than the programmed ddr sdram burst length, the ddr sdram controller must prevent the last data transfers from being written to memory. ddr sdram devices do not allow write bu rsts to be terminated, so the ddr sdram controller handles this by masking the last four data transfers (using dm) to prevent these from being written to the sdram. in the case of this write burst sequence, all the writes are to the same bank and row. if the second or third writes are to different banks or rows, the sdram controller issues precharge and/or active commands prior to the write commands.
timing diagrams coreddr v4.0 22 figure 5-1 coreddr burst write clk w_req r_req auto_pch raddr[30:0] b_size[3:0] rw_ack d_req datain dm_in dataout sa[13:0] ba[1:0] sc_n[7:0] ras_n cas_n we_n dq dm dqs local interface sdram interface write burst #1 write burst #2 write burst #3 address 1 address 2 address 3 42 0123456789 msk row column 1 column 2 bank chip 0l 0h 1l 1h 2l 2h 3l 3h 4l 4h 5l 5h 6l 6h 7l 7h 8l 8h 9l 9h ml mh write req #1 write req #2 write req #3
coreddr v4.0 sdram reads 23 sdram reads the user requests reads from the local bus interface by asserting the r_req signal and driving the starting address and burst size on raddr and b_size, respectively. the auto_p ch signal can also be asserted with r_req to cause the read to be issued as a read with auto-precharge . the rules for read requests at the local bus interface are as follows: 1. once r-req is asserted, it must remain asserted un til rw_ack is asserted by coreddr. after rw_ack is asserted by coreddr, r_req may remain asserted to request a follow-on read transaction. r_req may remain asserted over any number of rw_ack pulses to genera te any number of cascaded read bursts. the only time r_req may be deasserted is during the clock cycle immediately following the rw_ack pulse from coreddr. 2. raddr, b_size, and auto_pch must maintain static values from the point when r_req becomes asserted until coreddr asserts rw_ack. raddr, b_size, and auto_pch may only change values in the clock cycle immediately following the rw_ack pulse from coreddr, or when r-req is deasserted. 3. the r-req signal may not be asserted while the write request (w_req) signal is asserted. 4. the read data valid (r_valid) signal will assert when valid data is available on the dataout bus. the timing relationship between an initial r_req and rw_ack assertion, or between rw_a ck pulses as a result of multiple cascaded reads, will vary depending on the status of the banks being accessed, configuration port settings, refresh status and initialization status. the user logic should not rely on any fixed timing relationship between r_req and rw_ack. example coreddr read sequence figure 5-2 on page 24 shows an example ddr sdram controller read sequence. in this sequence, three reads are requested, all from the same row. the first and second read req uests are for a burst size of fo ur, and the third is for a burst size of two. the read request (r_req) signal is first asse rted with the starting address (raddr) and the burst size (b_size). as a result of this request, the ddr sdram cont roller asserts the row addres s (sa), bank address (ba), and chip select (cs_n) with the active command to open the bank to the requested row. next, the ddr sdram controller acknowledges the read request by asserting rw_ack, then issues the read command to the sdram devices. since the cas latency is set at 2.5 in this case, read data appears at the sdram interface 2.5 clock cycles after the read command is issued. the ddr sdram controller demultiplexes the data at the sdram interface and presents it to the local interface dataout bus. the ddr sdram controller asserts the r_valid signal to indicate valid data to the dataout bus. for this request, eight data transfers occur at the sdram interface, which translates to four data transfers to the local interface. the local interface read request (r_req) remains asserted after rw_ack is asserted by the ddr sdram controller to request an additional read burst. after the rw_ack pulse, the local interface changes the address (raddr) but keeps the burst size (b_size) at four. th e ddr sdram controller issues the next read command, and data transfers at the sdram interface immediately following the first burst. after the second read request, the ddr sdram controller co ntinues to assert r_req to cause a third burst. for this write, the burst size (b_size) is reduced to two. since th e burst size of the second read request is less than the programmed ddr sdram burst length, the burst must be terminated using the burst terminate command. the ddr sdram controller does this automatically, asserting cas_n two clock cycles after the read command was issued. this causes the sdram devices to discontinue the read after th e first four data transfers to the sdram interface. the sdram devices also stop driving the dqs clock signal.
timing diagrams coreddr v4.0 24 figure 5-2 coreddr burst read clk w_req r_req auto_pch raddr[30:0] b_size[3:0] rw_ack r_valid datain dm_in dataout sa[13:0] sa[10] ba[1:0] cs_n[7:0] ras_n cas_n we_n dq dm dqs address 1 address 2 address 3 42 0123 456789 row column 1 column 2 column 3 row[10] bank bank bank chip chip chip 0l 0h 1l 1h 2l 2h 3l 3h 4l 4h 5l 5h 6l 6h 7l 7h 8l 8h 9l 9h local interface sdram interface read req #1 read req #2 read burst #1 read burst #2 read req #3 read burst #3
coreddr v4.0 auto-precharge 25 auto-precharge read commands can be issued to the sdram devices as read with auto-precharge or read without auto-precharge . likewise, write commands can be issued to the sdram devices as write with auto-precharge or write without auto- precharge . if the auto-precharge option is used, the sdram device will automatically close (precharge) banks being read from or written to at the end of the transaction. any subsequen t reads or writes to this bank will not require an explicit precharge command from coreddr. the user selects whether read or write commands are issued with auto-precharge through the auto_pch signal. if auto_pch is asserted along with w_req or r_req, the command will be issued to the sdram with auto- precharge. the auto-precharge option is useful in situations where the requested read or write addresses tend to be random. with random address sequences, banks are seldom left open with the exact row required by a subsequent request. if auto-precharge is not used for the previous access to a bank, subsequent transactions to that bank first require the bank to be closed (precharged), causin g a delay in the transaction. if auto-precharge is used for the previous access, the bank is already closed and ready to be opened to the desired row. figure 5-3 on page 26 shows example transactions using the auto-precharge feature of coreddr. in the example, two write requests are issued, the first using auto-precharge an d the second not using auto-precharge. both requests are to the same bank but may be to different rows. coreddr issues the first command as a write with auto-precharge by driving bit sa[10] high during the write command. coreddr issues the second command as a write without auto-precharge by driving bit sa[10] low during the write command. since the first and second requests are to the same bank, coreddr must wait before reopening the bank to meet the sdram t wr and t rp requirements. had the first and second requests been to different banks, the second request would have foll owed the first request with no interruption to data flow.
timing diagrams coreddr v4.0 26 figure 5-3 coreddr burst writes with auto-precharge option clk w_req r_req auto_pch raddr[30:0] b_size[3:0] rw_ack d_req datain dm_in dataout sa[13:0] sa[10] ba[1:0] cs_n[7:0] ras_n cas_n we_n dq dm dqs address 1 address 2 4 0123 4567 row column 1 column 2 row column 2 bank chip local interface sdram interface write req w/ auto-precharge write req w/ auto-precharge t wr t rp
27 6 testbench operation two testbenches are provided with coreddr: ?verilog testbench ?vhdl testbench testbench description included with the obfuscated and rtl releases of coreddr is a user testbench that gives an example of coreddr usage. a simplified block diagram of the testbench is shown in figure 6-1 . by default, the verilog version, tb_user.v, instantiates a micron sdram model (mt46v8m16 .v ). the vhdl version, tb_user.vhd , instantiates a micron sdram model (mt46v8m16 . vhd). the testbench instantiates the dut (design under test), which is the coreddr macro, the sdram model, as well as the test vector module s that provide stimuli sources for the dut. a procedural testbench controls each module and applies the sequential stimuli to the dut. figure 6-1 coreddr testbench verilog user testbench the verilog user testbench is provided as a reference and can be modified to suit your needs. the source code for the verilog user testbench is provided to ease the process of integrating the coreddr macro into your design and verifying its functionality. vhdl user testbench the vhdl user testbench is provided as a reference and can be modified to suit your needs. the source code for the vhdl testbench is provided to ease the process of integr ating the coreddr macro into your design and verifying its functionality. procedural testbench sdram model coreddr

29 7 implementation hints data capture there are two ways of achieving data capture with ddr: self-timed and by use of the distributed queueing system (dqs) strobes. due to lack of multiple dll elements in proasic3e technology and the relatively low speeds (<200 mhz), actel recommends the self-timed approach. handling the data capture from dimm self-timed mode requires the controller to generate a data sample clock that captures the incoming data ( figure 7-1 ). ideally this is 90 phase-shifted from the main clock; in real ity, allowance has to be made for propagation delays. the dimm (ddrram) generates data on both th e positive and negative clock edges. the secondary clock of the pll is ideally a 90 phase-shifted clock and needs to sample the data correctly. when capturing data, the 90 phase-shifted clock should sample the data clock to the mid point of the data window. figure 7-1 self-timed mode the dimm (ddrram) generates data on both the positive and negative clock edges. the fpga will ideally clock on the 90 phase-shifted clock and correctly sample the data. du e to the propagation delays, however, the data is not captured correctly. the 90 phase-shifted clock is replaced with the clkdly cell to adjust the delay values and capture the data properly, as shown in figure 7-3 on page 30 . the best and worst case signal prop agation delays are calculated in delay calculation on page 30 . in the proasic3e-2 part, the data round trip delay from the internal clock to the data arriving at the sample register at worst case conditions is 4.85 ns. the be st case conditions is 2.5 ns ( figure 7-2 ). figure 7-2 signal propagation delays fpga clk clk_in coreddr pll clk_1x clk_1x_sh90 dimm q s r set clr q s r set clr q q set clr q s r q 0 ns 2 ns 4 ns 6 ns 8 ns 10 ns 12 ns clock clock90 data_ideal[63:0] data_best[ 63:0] data_worst[ 63:0] data_range[63:0] tde l tbc twc
implementation hints coreddr v4.0 30 note: in figure 7-2 on page 29 we assume that the secondary clock, which has a phase shift of 90, is ideal. the sample points (rising edge and falling edge ) are in red. the data_best shows the fastest that the data can change (2.5 ns round trip) and data_worst the slowest (4.85 ns round trip). the data_range indicates when the data should be valid at the capture register. what we want to achieve is that the sample clock hits the midpoint of the data window. eq 7-1 is the equation for calculating the clock delay (for the clkdly cell in the proasic3e fpga cell library) to achieve this midpoint sample. definitions tbc = best case data round trip delay twc = worst case round trip delay tclk = system clock period tdel = delay needed to shift the capture clock dll delay = (tclk/2 +tbc + twc)/2 ? tclk/2 eq 7-1 = (tclk/2 +tbc + twc ?tclk)/2 = (tbc + twc ? tclk/2)/2 using typical figures obtained with an a3pe600fg484-2 part and a socketed, mounted 1 gb dimm module we get = (2.5 + 4.85 ? 3.75)/2 tdel = 1.8 ns (equivalent to 86 shift from the system clock) from eq 7-1 , the clock delay macro should be generated with a delay of 1.8 ns to capture the data correctly, as shown in figure 7-3 . figure 7-3 data capture delay calculation worst case delay calculation 1. clk output pad = 1.6 ns 2. pcb delay to dimm = 0.61 ns 3. clkk_out on dimm = 0.75 ns 4. pcb delay to fpga = 0.6 1 ns fpga clk clk_in coreddr pll clkdly clk_1x clk_1x_sh90 dimm q s r set clr q s r set clr q q set clr q s r q
coreddr v4.0 data capture 31 5. input pad delay to ddr reg = 0.996 ns 6. setup at ddr reg = 0.282 ns adding the numbers from 1 through 6 gives a worst case delay of 4.85 ns. best case delay calculation 1. clk to output pad = 0.86 ns 2. pcb delay to dimm = 0.43 ns 3. clk_out on dimm = 0 ns 4. pcb delay to fpga = 0.43 ns 5. input pad delay to ddr reg = 0.6 ns 6. setup at ddr reg = 0.203 ns adding the numbers from 1 through 6 gives a best case delay of 2.5 ns.

33 8 ordering information ordering codes coreddr can be ordered through your local actel sales representative. it should be ordered using the following number scheme: coreddr-xx, where xx is listed in table 8-1 . table 8-1 ordering codes xx description om rtl for obfuscated rtl C multiple-use license rm rtl for rtl source C multiple-use license note: coreddr-om is included free with a libero ide license.

35 a list of document changes the following table lists critical changes that were made in the current version of the document. previous ver si o n changes in current version ( ) page v2.2 the signal names were all made upper case. n/a the buffers were removed from figure 1-1 typical coreddr system . they are depicted more completely in figure 1-2 ddr sdram controller block diagram . 7 the address mapping section was revised to state that column bits, bank bits, row bits, and chip select are mapped from the least significant bits of raddr. 9 figure 2-1 coreddr configuration within smartdesign was replaced. 13 table 3-1 coreddr generics was revised to remove the parameters sdram_banks, sdram_oe_bits, and sdram_bankbits, and sdram_rasize. the defaul t setting for program second pll with this delay was changed to 1.335 ns. 15 the text preceding table 3-3 example controller parameter values for coreddr was revised. 17 the description for clk_1x_sh90 in table 4-1 local bus signals was revised to change C90o to 90. 19 the sdram reads section was revised to correct errors in points 1 and 3 so that read is used with the r_req signal and write with the w_req signal. 23 v2.1 the core version was chan ged from v3.0 to v4.0 n/a the key features section is new. 5 fusion was added to the supported device families section . 5 table 1 coreddr device utilization and performance was expanded to include fusion. 5 the tool flows section was revised. the evaluation version is no longer available. coreconsole was replaced by smartdesign. 13 table 3-1 coreddr generics was revised to add fusion as an available setting for the fpga family generic. 15 testbench description section was revised. 27 the verilog testbench section was replaced by the verilog user testbench section . the vhdl testbench section was replaced by the vhdl user testbench section . 27 the ordering information chapter is new. 33 v2.0 the supported device families section was added. 5

37 b product support actel backs its products with various support services including customer service, a customer technical support center, a web site, an ftp site, electronic mail, and worldw ide sales offices. this append ix contains info rmation about contacting actel and usin g these support services. customer service contact customer service for non-technical product support , such as product pricing, product upgrades, update information, order status, and authorization. from northeast and north central u.s.a., call 650.318.4480 from southeast and southwest u.s.a., call 650. 318.4480 from south central u.s.a., call 650.318.4434 from northwest u.s.a., call 650.318.4434 from canada, call 650.318.4480 from europe, call 650.318.4252 or +44 (0) 1276 401 500 from japan, call 650.318.4743 from the rest of the world, call 650.318.4743 fax, from anywhere in the world 650.318.8044 actel customer technical support center actel staffs its customer technical support center with highly skilled engineers who can help answer your hardware, software, and design questions. the custo mer technical support center spends a gr eat deal of time creating application notes and answers to faqs. so, before you contact us, please visi t our online resources. it is very likely we have already answered your questions. actel technical support visit the actel customer support website ( www.actel.com/support/search/default.aspx ) for more information and support. many answers available on the searchable web resource include diagrams, illustrations, and links to other resources on the actel web site. website you can browse a variety of technical and non-technical information on actels home page , at www.actel.com . contacting the customer technical support center highly skilled engineers staff the technical support center from 7:00 a . m . to 6:00 p . m ., pacific time, monday through friday. several ways of co ntacting the center follow: email you can communicate your technical questions to our email address and receive answers back by email, fax, or phone. also, if you have design problems, you can email your design files to receive assistance. we constantly monitor the email account throughout the day. when sending your request to us, please be sure to include your full name, company name, and your contact information for effi cient processing of your request. the technical support email address is tech@actel.com .
product support coreddr v4.0 38 phone our technical support center answers all calls. the center re trieves information, such as your name, company name, phone number and your question, and then issues a case number. the center then forwards the information to a queue where the first available application engineer receives the data and returns your call. the phone hours are from 7:00 a . m . to 6:00 p . m ., pacific time, monday through friday. the technical support numbers are: 650.318.4460 800.262.1060 customers needing assistance outside the us time zones can either contact technical support via email ( tech@actel.com ) or contact a local sales office. sales office listings can be found at www.actel.com/company/c ontact/default.aspx .
39 a actel electronic mail 37 telephone 38 web-based technical support 37 website 37 address mapping 9 auto-precharge 25 auto-refresh 10 , 12 b bank management 5 , 12 block diagram 7 bus commands 9 c cas latency 10 contacting actel customer service 37 electronic mail 37 telephone 38 web-based technical support 37 controller configuration ports 16 core versions 5 customer service 37 d ddr sdram interface signals 20 device utilization and performance 5 dqs 29 g general description 5 generics 15 i initialization sequence 11 instruction timing 11 k key blocks 7 l libero ide importing into 14 place-and-route 14 simulation 14 synthesis 14 licenses 13 local bus signals 19 o obfuscated version 13 operation 9 ordering code 33 ordering information 33 p place-and-route in libero ide 14 product support 37 ? 38 customer service 37 electronic mail 37 technical support 37 telephone 38 website 37 r refresh operations 10 timing 12 rtl 13 s sdram device configurations 10 reads 23 writes 21 self-timed mode 29 signal propagation delays 29 simulation flows 14 smartdesign 13 synthesis in libero ide 14 system blocks 7 t technical support 37 testbenches description 27 operation 33 verilog tests 27 verilog verification 27 vhdl tests 27 vhdl user 27 index
40 index coreddr v4.0 typical system 7 v verilog testbench tests 27 verification testbench 27 vhdl testbench tests 27 user testbench 27 w web-based technical support 37

actel corporation ? 2061 stierlin court ? mountain view, ca 94043 ? usa phone 650.318.4200 ? fax 650.318.4600 ? customer service: 6 50.318.1010 ? customer applications center: 800.262.1060 actel europe ltd . ? river court, meadows business park ? station approach, blackwater ? camb erley surrey gu17 9ab ? united kingdom phone +44 (0) 1276 609 300 ? fax +44 (0) 1276 607 540 actel japan ? exos ebisu building 4f ? 1-24-14 ebisu shibuya-ku ? tokyo 150 ? japan phone +81.03.3445.7671 ? fax +81.03.3445.7668 ? http://jp.actel.com actel hong kong ? room 2107, china resources building ? 26 harbour road ? wanchai ? hong kong phone +852 2185 6460 ? fax +852 2185 6488 ? www.actel.com.cn 50200109-2/5.09 actel is the leader in low-power and mixed-signal fpgas and offers the most comprehensive portfolio of system and power management solutions. power matters. learn more at www.actel.com.

▲Up To Search▲

Price & Availability of COREDDR-M

	To Download COREDDR-M Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .